The present invention relates to the field of software licensing, and, more particularly, to token based licensing of software tools having token costs that vary based upon a set of features enabled for the software tools.
Many models exist for software licensing. License models include per product license, user based licenses, and concurrent use licenses. One specific license model, referred to as a token license model, utilizes tokens instead of a specific number of licenses that correspond to a discrete software tool. In the token license model, use of a software tool can consume a quantity of tokens from a previously established token pool. Different software tools can be designed to use the token pool, each of which can be associated with a tool specific quantity of tokens. Customers requiring additional usages of token consuming tools can purchase additional quantities of tokens, which are added to the token pool.
Traditional token license models associate a fixed token cost per software tool. In this sense, each software tool is handled by the licensing system implementing token license model as a uniform, discrete entity having a fixed token cost. There is a disconnect from this assumption, however, and real-world realities. This disconnect results in a market bias that disfavors venders of more sophisticated tools.
To elaborate, venders of software tools can choose to implement these tools in a myriad of ways, each of which results in different customer derivable values and each resulting in different vender costs for implementing the software tool. Many design choices that incur significant incremental costs relate to providing advanced features, such as providing capabilities for broad support for a large set of integrated tools, for sophisticated and automated operational guidance, user-directed data customizations, and for high concurrent usages. These advanced features can require substantial implementation complications and overhead, which are not inherent in implementing approximately equivalent software tools that lack the advanced features. Once a software tool has been implemented, it can be impossible or disproportionately costly to upgrade the implemented software tool to include previously lacking advanced features, as these features may require extremely low-level adjustments to a software tool. That is, the adjustments for many advanced features can require structural or fundamental changes, which can require a complete re-write of the software tool.
Traditional market bias disfavoring sophisticated software tools results from cost decisions being driven at a particular point in time, typically during an initial purchase period for a tool. A purchaser of a tool, who does not initially have a need for advanced features or who is unaware of this need, will likely opt for low-cost solution, which lacks these features. As the software tool is utilized, however, and as a purchaser begins to rely upon it, a need for more advanced features can emerge and/or can become more evident. Purchasers are locked into a selected tool for at least a period defined by purchased tokens or other licensing agreements. Further, migration from an original tool lacking advanced features to one including advanced features is often far from seamless and can be costly in terms of data migration, required training, and other such factors. These are costs in addition to the “upgrade cost” or the delta between the cost for the advanced feature enabled software tool and the software tool lacking such a feature.
Additionally, tool providers attempt to establish sets of “advanced features” commensurate with market value/implementation costs. These pre-packaged bundles (such as basic, standard, advanced, enterprise) often do not permit users to select their own desired feature set. That is, a user may desire a given advanced feature present in an enterprise bundle, yet not desire other features of that bundle, where the strength of feature desire is insufficient to justify the incremental cost incurred between the advanced and enterprise bundle. Thus, a rigid scheme of pre-packaging feature sets for set-defined costs does not provide an optimal market return on a per-feature basis.